\subsection{Motivation and general experiences}
We choose to use reqT because it enabled us to take a database approach to constructing the requirements document. We were amazed by the short learning period reqT required, we were able to get up and running and become fairly fluent within short of an hour. 

One downside was that the documentation was lacking and we were not fluent enough in Scala to make sense of the reqT source code just yet. This meant that the main source of documentation was the introduction lecture on reqT. This lack of documentation caused some of a misunderstanding in the beginning as we thought that reqT was tree based. Tree based meaning that each feature was a root having sub features and functions and so forth.

We also thought that when you created a has relation to a feature, the new feature would be created. Since Scala did not give any warnings we thought the new feature was created. Unfortunately this was not the case. This particular problem caused a lot of data loss in rd v1.0. We later found out that the relations actually were stored, but at that point we had already recreated them and restructured the document.
\subsection{Methods}
During the project we had the pleasant opportunity to help give feedback and in some cases alter and improve reqT. It was a very different and fun experience to see reqT grow with us during this project. 
\subsubsection{Method 1 - The good but slow method}
Our first approach was having one driver who created the requirements in reqT via the Scala command line. This technique worked great when there were only students working on elicitation. We also found it to be faster inputting requirements directly in reqT instead of on paper first, this lead us to want to have more than one reqT driver. 

When trying to solve this problem we ran into three major subproblems. The first being that Scala required quite a lot of disk space (this of course in comparison to the user disks on the school computers). 

The second problem was that it was kind of hard to get the reqT generated files to play nice with svn. The third and final major problem was that we needed to work in parallel to be able to finish in time to the deadline. What we ended up doing resulted in the second method.
\subsubsection{Method 2 - The first parallel method}
Since Scala required a lot of disk space we chose to export our main reqT file to a .scala file and upload it to Google docs. This solved the problem with the Scala diskspace. It also enabled us to work in parallel with a breeze. One down side was that we could not use SVN to full extent but luckily Google docs also has version tracking. 

This solution however was far from ideal. This since it was much harder to get an overview of the entire document since you could not directly compile from Google docs. Also, in Google docs we did not have the benefit of the Scala command line telling us when the syntax was wrong, nor did we have syntax highlighting to help us on the way. 

This resulted in a lot of "compilation errors" or should I say :load-ing errors. Another small headache was that Google docs changed quotes to those American print quotes by default causing reqT to go totally bonkers when trying to load the Google docs .scala file. There was also something weird happening with the line endings resulting in a lot of unnecessary manual labour to compile the .scala file. 

By this time it was getting pretty far into the project and we started to need to prioritize our requirements. Since we wanted to use focal point we requested a tabsep export, which to my understanding was already in the works by the time we requested it. This new Tabsep export functions gave us an idea to improve the currently used method which resulted in method 3.
\subsubsection{Method 4 - The almost ideal method}
When exporting the requirements for use in focal point we noticed that we got a really good overview of our requirements in excel. This resulted in us immediately requesting a tabsep import as well. With this new import function we explored a new working method where we first created one big Scalafile, exported it as a tabsep .txt then imported it to an excel spreadsheet and imported that spreadsheet to Google docs where we worked in parallel on the big spreadsheet. 

This new import function was awesome since it eliminated all the Google docs problems we previously had. To get a better overview we split the big Scala file into smaller chunks for which we wanted to create separate chapters in the requirements document.

This was made possible by the chapter functionality in reqT, unfortunately this chapter functionality required that we added each entity separately, since the chapter functionality did not support us adding everything from a domain, and we had over 200 entities in the finished document, we simply did not have the time to add every entity to the corresponding chapter which sadly rendered the chapter functionality we requested useless until it supports adding a whole domain. 

There is however one problem with the tabsep export, it does not support relations. This resulted in us having to redo all our relations for each separate file. Fortunately we discovered this to be a really awesome validation technique but this rendered the spreadsheet files useless for "development" purposes. Luckily now the smaller Scala files were small enough to work on and still be able to get a decent over view. To avoid having to load each separate file and merge them to a single domain we created a "Make file" where we just loaded each file and then exported the merged domain as both a Scala file and a .tex file. By this time we started to really enjoy working with reqT. 
\subsubsection{Method 5 - The ideal awesome method}
Lastly, we will try to describe the ideal working method, with some improvement suggestions to reqT. If we would start over on a new project we would start by grouping the requirements into some subdomains, each resulting in a separate .scala file which we would add to the make file. The make file would ideally also create the chapters and, if reqT could, import each separate domain to the specific chapter. 

The makefile would also specify which latex packages to include when generating the tex document. Then we would export the Scala files as tabsep .txts and upload them to Google docs enabling seamless merge conflictless parallel development on Google docs spreadsheets. Do some hardcore development on Google docs, and then import them to reqT again.

When in reqT we would create the relations needed. We do not have any good solution to handling relations in the spreadsheets but there definitely has to be some way to keep the relations in the tabsep file, just for "safekeeping". The best way to handle relations we feel is to use reqT, since it handles these really well. One more thing that we miss is unique identifiers for each requirement, ideally you would be able to, for each domain specify a starting string, or number for which the later added requirements, unique IDs would be based on.

This would help a lot in enabling as much traceability as possible. We do not feel that the transform operator is enough to enable full traceability. For the traceability in the course necessary for the grades, we consider the best way if you have less than 60 requirements to just cite said requirements in the specific elicitiation or specification techniques, but if there are more than 60 requirements it is much more useful to cite the origin of the elicitation and specification with the requirement in reqT. The supervisors may not agree with this as they did not think writing the elicitation/specification technique at the requirement was readable but that the requirements have to be written at the techniques to not cause confusion.
\subsection{Improvements}
In addition to the previously stated potential improvement, the only additional improvements that we could think of is simply to have more lectures on reqT, this since the first introduction lecture on reqT mainly focused on Scala and we did not get enough hands on experience.

A second lecture focusing on reqT and how to integrate it in the project would have been nice. Also the differences between reqT and the course book must be made clearer as there were a lot of conflicts with the supervisor which were caused by the reqT generated document rather than the actual content. 

Another thing that we think we could have benefited from would have been a reqT experiment where you went through some simple scenarios, the Focal Point experiment could also include a section on how to integrate it with reqT (this was not very hard but it would have helped to avoid some unnecessary headache). 
